<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Testbeds - Setup and Interfaces</title>
<meta name="author" content="Jan Beutel" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2009-02-03 23:07:32 $
:version: $Revision: 1.2 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/
body {
  font-family: Times;
  font-size: 16px;
}

.first {
  margin-top: 0 ! important }

.last {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dd {
  margin-bottom: 0.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 0em 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1 {
  font-family: Arial, sans-serif;
  font-size: 20px;
}

h1.title {
 text-align: center;
 font-size: 32px;
}

h2 {
 font-size: 16px;
 font-family: Arial, sans-serif;
}

h2.subtitle {
  text-align: center }

h3 {
 font-size: 12px;
 font-family: Arial, sans-serif;
}

hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee;
  border-color: #000000;
  border-width: thin; 
  font-size: 14px
}

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.citation {
  border-left: solid thin gray ;
  padding-left: 0.5ex }

table.docinfo {
  margin: 2em 4em;
}

table.footnote {
  border-left: solid thin black ;
  padding-left: 0.5ex }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

th.docinfo-name, th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap;
  }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {}

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="testbeds-setup-and-interfaces">
<h1 class="title">Testbeds - Setup and Interfaces</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">130</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Testbeds Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">All</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Jan Beutel</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">14-Jun-2007</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.2</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-06-28</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Testbed WG &lt;<a class="reference" href="mailto:tinyos-testbed-wg&#64;eecs.harvard.edu">tinyos-testbed-wg&#64;eecs.harvard.edu</a>&gt;&gt;</td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This document specifies a Best Current Practices for the
TinyOS Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.</p>
</div>
<div class="section">
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo describes the structure and interfaces required for TinyOS compliant
testbeds.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>The testing and validation of embedded code on real hardware is key to
successful development of TinyOS applications. Although popular and powerful for
high level analysis, current simulation methods lack in terms of level of
detail and accuracy when used accross multiple system layers where abstractions
and models used are inherently imperfect and impair results. Methods such as
hardware emulation commonly used in embedded system development allow the
execution of code on a hardware platform and therefore can guarantee timing but
are very limited in terms of scalability and often confined to a lab usage only.</p>
<p>Sensor network testbeds try to overcome these deficiencies by allowing to execute
software code under realistic operating conditions on real hardware embedded in
a target environment. This approach allows to generate a level of detail especially
in respect to the whole system (radio. processor, storage, sensors, interfaces)
and the wireless environment (noise, fading, shading, errors, failures) while
maintaining a certain degree of scalability. Remote programming as well as a
feedback of status and debugging information from the nodes using testbed
infrastructure alleviates the need for integrated services in sensor network
applications. Additionally testbeds allow to operate a set of nodes in a
controlled environment, i.e. using temperature variations or a controlled
wireless environment.</p>
<p>A typical testbed is made up of a number of nodes (?do we state amounts here?)
connected to a central resource for control and logging that are deployed in a
physical space (testing area). Typically the central resource is a server with
integrated datalogging capability. Often a web front end serves as a simple control and
visualization resource. For the submission of testing jobs and the analysis of
testing results external tools are attached to the central resource using a
standardized interface. This document serves as a key specification document for
such an interface and its intended usage.</p>
<p>MISSING: Difference of a testbed vs. a desktop test (e.g. single nodes with a
programmer or a simple usb grid)</p>
<p>Examples of currently used sensor network testbeds are MoteLab [<a class="reference" href="#id1">1</a>] and the
Deployment-Support Network [<a class="reference" href="#id2">2</a>].</p>
</div>
<div class="section">
<h1><a id="testbed-usage" name="testbed-usage">2. Testbed Usage</a></h1>
<p>A testbed can serve different purposes depending on the development status and
requirements of a specific project. While this document does not target to restrict
such usage it defines a set of mandatory modes of operation that a testbed must
be able to support:</p>
<p>Modes of Operation:</p>
<ul class="simple">
<li>Single Shot Operation</li>
</ul>
<p>Execute a testing job consisting of an uploading of a specific code image onto a
set of nodes, remote programming of nodes using a testbed resource, the
synchronized start of this software, capture of resulting target response, the
centralized storage and timestamping of all actions and target response, ending
of test execution, notification of a user of the end of test execution, output
of all stored data on demand.</p>
<ul class="simple">
<li>Repetitive (e.g. using continuous integration or for regression testing)</li>
</ul>
<p>A concatenation of single shot testing jobs, that in practice often will be used
with the variation of one or more parameters.</p>
<ul class="simple">
<li>Long Term Operation (Profiling)</li>
</ul>
<p>Other Topics:</p>
<ul class="simple">
<li>Federated Testbeds (in multiple environments)</li>
<li>Access/Resource Arbitration</li>
<li>Scheduling of testing jobs</li>
</ul>
</div>
<div class="section">
<h1><a id="testbed-services" name="testbed-services">3. Testbed Services</a></h1>
<p>Required Services:</p>
<ul class="simple">
<li>identification of target devices (presence, type, hw rev)</li>
<li>programming of target devices</li>
<li>resetting of target devices</li>
<li>logging of target response (UART mandatory, IRQ optional)</li>
<li>versioning/identification of uploaded software</li>
<li>identification/versioning/archiving of testing jobs</li>
<li>testbed status information</li>
<li>identification of testbed services</li>
<li>user authentification</li>
</ul>
<p>Optional:
- power measurements
- stimuli
- distributed scheduling of actions (at nodes)</p>
</div>
<div class="section">
<h1><a id="implementation" name="implementation">4. Implementation</a></h1>
<ul class="simple">
<li>Server, DB/Storage, Interface XMLRPC</li>
<li>Connection fabric</li>
<li>On- and offline logging</li>
<li>Supplied Power</li>
<li>Mote Hardware</li>
</ul>
<p>THINGS TO DISCUSS</p>
<ul class="simple">
<li>?Do we state minimum requirements?</li>
<li>number of nodes</li>
<li>power supply (fixed/batt)</li>
<li>power profiling</li>
<li>power on/off of targets? is simple reset/erasing enough?</li>
<li>feedback channel capabilities (delay, errors, lost packets...)</li>
<li>target control? is control of (writing to) targets required or is it an optional feature?</li>
<li>scheduling of actions (time synched???)</li>
</ul>
</div>
<div class="section">
<h1><a id="reference" name="reference">5. Reference</a></h1>
</div>
<div class="section">
<h1><a id="acknowledgments" name="acknowledgments">6. Acknowledgments</a></h1>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">7. Author's Address</a></h1>
<div class="line-block">
<div class="line">Jan Beutel</div>
<div class="line">Gloriastr 35</div>
<div class="line">ETH Zurich</div>
<div class="line">8092 Zurich</div>
<div class="line">Switzerland</div>
<div class="line"><br /></div>
<div class="line">phone - +41 44 632 7032</div>
<div class="line"><br /></div>
<div class="line">email - <a class="reference" href="mailto:j.beutel&#64;ieee.org">j.beutel&#64;ieee.org</a></div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">8. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id1">[1]</a></td><td>G. Werner-Allen, P. Swieskowski, and M. Welsh. MoteLab: A wireless sensor
network testbed. In Proc. 4th Int'l Conf. Information Processing Sensor
Networks (IPSN '05), pages 483-488. IEEE, Piscataway, NJ, April 2005.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id2">[2]</a></td><td>M. Dyer, J. Beutel, L. Thiele, T. Kalt, P. Oehen, K. Martin, and P. Blum.
Deployment support network - a toolkit for the development of WSNs. In Proc.
4th European Workshop on Sensor Networks (EWSN 2007), volume 4373 of Lecture
Notes in Computer Science, pages 195-211. Springer, Berlin, January 2007.</td></tr>
</tbody>
</table>
</div>
<div class="section">
<h1><a id="appendix-a-example-appendix" name="appendix-a-example-appendix">Appendix A. Example Appendix</a></h1>
<p>This is an example appendix. Appendices begin with the letter A.</p>
</div>
</div>
</body>
</html>
